[ Apologies for Debian planet readers expecting something pithy and Debian related. This isn't. But then pkg-xfce packaging just continues. We get more bugs, we fix some of them (if you have a dual-headed setup and want to help us fix or reproduce more we'd love to hear from you). Corsac became a DD at last and has made me more or less redundant in a good way. I should probably investigate libburnia again and prod George Danchev about #450873 since basically it seems to just need the ubuntu packaging brought across into Debian to replace libburn etc. But anyway, on with the irrelevant stuff... ] Books part 1 was back in April and I've since found myself with some time on my hands before I get a new job so here we go again.

Making Money - Terry Pratchett

This was a Christmas present and I quite enjoyed it and enjoyed the character but didn't really think it lived up to the laugh a minute Pratchett books that I remembered from the good old days.

The Lovely Bones - Alice Seebold

This is quite a weird concept for a book given that it's from the point of view of a dead girl in heaven but it seems to work. It's very well done and I enjoyed it.

Alex Rider series - Anthony Horowitz

I had seen Stormbreaker and wanted to read some more of these as light holiday reading. They work well for that. There's enough plot to keep me interested but not enough to make them at all hard to read. I read a couple of them in French when I was in France (in between traipsing between different bits of Paris since the m tro workers were on strike). I wish they'd been around when I was younger.

My Sister's Keeper - Jodi Picoult

Ooh this is a really, really good book. I loved it except perhaps for the very end but I can forgive it that. The idea is that she's suing her parents for the rights to her own body because she was conceived as a donor for her sister to fight off her sister's leukaemia. It's a very thought provoking read with several interesting characters with their own stories woven together.

The Language Instinct - Steven Pinker

This book is fascinating to me. It takes ideas mainly from linguistics, evolution and psychology and explains a theory that seems to hold together and is well illustrated and explained. The central point is that we all are born with the ability to develop a universal grammar from an early age which can be adapted to any human language and which sticks around in the young child and then disappears. If you have any interest in language at all read this book.

A Spot of Bother - Mark Haddon

I found this a bit hard to get into as essentially it's about the normal lives of a family (albeit quite a special family). It doesn't really grab you. Towards the end though I was interested to find out how it would all unravel and was pleased with it.

The Mephisto Club - Tess Gerritsen

This is a nice, honest thriller that does what you expect. It keeps you flicking the pages wanting to know what happens next.

The God Delusion - Richard Dawkins

I quite enjoyed this and did find new arguments against religion but I don't think he's going to convert anyone with this book. Of course I'd recommend anyone read it because it raises lots of interesting points but it's polemic essentially.

The Blind Watchmaker - Richard Dawkins

I enjoyed this though it builds on previous work I'd read. I guess if you're just interested in evolution then read this and not the God Delusion.

The Raw Shark Texts - Steven Hall

I was recommended this by a friend. It's very surreal possibly a bit too surreal for me but I enjoyed it nonetheless.

Do Androids Dream of Electric Sheep? - Philip K Dick

I hadn't read the book and saw it at a friend's and borrowed it. You probably all know what it's like. I'm glad I read it because of the references to it but it's not my normal reading material.

Harry Potter and the Deathly Hallows - J K Rowling

I had to read this of course to finish off the series but I thought it was a lot better than some of the others. I think I enjoyed the first, the one with the tri-wizarding championship and this one the most.

Love in Idleness - Charlotte Mendelson

This is well written and you really get into the character that's painted for you. I really liked some of the descriptions of justifying things to yourself and coping with boredom.

Blood, Sweat & Tea - Tom Reynolds

This was an interesting look at the life of a paramedic and if you don't already read Random acts of reality then read the book first and start reading the blog.

Telling Lies - Paul Ekman

This came from my Blink/Tipping Point reading and I found it hard going. It was interesting but quite detailed and not really a book for late night reading. The theories in it are very interesting though and explain why you probably aren't as good at detecting things as you think you might be and how to look for factors that will help you.

The Man Who Mistook His Wife for a Hat - Oliver Sacks

I read this ages ago and it was fascinating. It's about a number of different cases of problems with the brain. Often physical defects in various areas of the brain that cause odd problems and how it sheds light on how things relate. I really enjoyed it.

As always, do please punt your own recommendations at me.

Hey everybody! Etch users will be pleased that they know have access to Xfce 4.4.2 backports in their favorite distribution. This release seems to fix the well known memory leaks in xfdesktop and xfce4-menu-plugin, so if you run Debian Etch on your desktop and are annoyed by them, you can try the backports. Everything is explained at backports.org website.

Yzah! At last, I am now an official Debian Developer. My account was created this night by James Troup, so now the waiting is over. 2+ years, pfiou. Now let's get back to work! Thanks everyone. 

Congratulations to Yves-Alexis Perez (Corsac), Nicolas Fran ois (Nekral) and Sune Vuorela (Pusling) too \o/ Finally, some accounts (~30 ?) were created and i’m in. Thanks to all people involved in Debian and Kubuntu. In particular (no order) my co-maintainers, sponsors, helpers and application manager:
* Pierre habouzit (Madcoder)
* Mark Purcell (msp)
* Ana Beatriz Guerrero (Ana)
* Enrico Zini (enrico)
* Gustavo Franco (stratus)
* Lo c Minier (lool)
* Jonathan Riddell (riddell)
* Sarah Hobbs (hobbsee)
* and many many others But I don’t forget other people who missed this train: Cyril Brulebois (kibi). Next time, it’s your turn ! (i hope soon).

But you won't have it in your favorite distro. Not yet. Not yet even if the packages are ready since more than a week (thanks to unofficial release by Xfce team to have it tested by packagers), and they only need the last checks before upload. No, you won't have it today because this week, like the previous, and the previous, and the previous:  0 applicants became maintainers. Just. too. bad. 

The current status of the NM process, with 1 NM awaiting FD approval, 7 awaiting DAM approval, and 30 waiting for their accounts to be created, leads people to thinking that the big bottleneck is the account creation stage. However, when you look at what happened since december 2005, it’s not that simple. See the graph linked above, which shows where people are waiting. While it seems that the FD stage hasn’t been blocking people for nearly a year, it’s the DAM stage which has been the biggest blocker. Indeed, on average, 8.3 NMs have been blocked by FD, 16.2 by DAM, and 9.0 by account creation. I understand that processing NM reports in batch mode makes it more efficient. However, I’m wondering if processing them 20 per 20, is really that more efficient than processing them 5 per 5, which would justify such long queues. The NEW queue, which used to be a problem, is now being processed on a very regular basis, and hasn’t grown widely recently, except after Debconf when the ftpmaster processing NEW was on VAC. Couldn’t we have the same thing for DAM, account creations, and while we are at it, removals from unstable? Having clearly defined human-crontab-jobs would certainly make working on Debian less frustrating.

After massive processing of new queue during weekend (check graphs to get better impression, kudos to all who managed to handle hundredth of packages during weekend), new Gammu is in unstable. It is still not in shape for migration to testing, but it is much better than the one I accidentally uploaded before. Currently there are no known open regressions, so if you see something failing what used to work before, just report it!

If you're running Debian lenny (testing) and since the last upgrade it seems that Xfce freezes randomly, you're not crazy, it's a real bug (#449050 and #449134 already reported). xfwm4 freezes in certain condition with gtk 2.12 wich has entered testing yesterday. xfwm4 4.4.1-3 in unstable fixes the problem, and it'll reach testing really soon now (it just built on arm and should transition in the next days). In the meanwhile you should be able to take the unstable package and install it on testing without problem. Sorry for the mess, from the pkg-xfce team.

Today, it's been two years I'm stuck in the NM queue. I've registered on oct 24, 2005, because Sam Hocevar told me that it could last a little, so if I was interested I should register early. I wondered for a long time if I should resign on this two years birthday, but I dropped this eventuality. I still want to be a Debian Developer, and if I resign I don't think I'll really want to still work on Xfce packages. But on the other hand I wouldn't really like to use an Xfce not packaged by me (no offense, but I guess I'd still want to hack on it) and I don't think I would be able to be on another distro. So I'm still there, sitting in NM queue, waiting for the next step. The only required step to be accepted as a Debian Developer is to have its gpg key added to the debian keyring (then an account is created on debian boxes, there's a -private subscription etc.). This is done by a team, called DAM, "Debian Accounts Managers". Because at one time they had a lot of work, they could not examine each candidate and decide if he was a potential good Debian Developer, so people imagined the NM Process: some volunteers would help them asking questions to candidates, then write a report, so DAM would only have to read it and decide if it was ok or not to create an account. I've already passed this step. I am "DAM Approved". One could imagine that, if the Debian *Accounts* Managers reviewed and approved my application, the account creation should follow. But no, the next step (according to NM pages) is "DAM creates account or rejects application". The problem here is that there is no "DAM Team", responsible for Debian accounts, but various people which are not really equivalent in this team. This is really a problem in Debian, where teams aren't really a "team". Not every team I guess, but in some cases one can trust a team to do a job. Debian is a volunteer organisation, so people think nobody can be forced to do a job if he doesn't have time to it. I'm fine with that, real life can be really time-consuming sometime. But my opinion is that teams may have to be forced to do their job. If nobody in the team has time, fine, it means somebody should join the team. But the team itself shouldn't fail, and this should be the only thing visible from outside: the "team", and the team actions. There are some proposition about this on lists at the moment, but I don't really know how it'll end. It's not easy doing social stuff, there's a lot of people involved, with many different views. But sometimes the consensus is *not* findable, and sometimes, somebody has to decide. That's why why need team leaders, and that's the project leader role. I guess people are quite opposed to have a "strong" leader in a volunteer organization, and I don't have concrete proposals but I really thing team management is not really perfect and a lot of people (users and developers) suffer from that (not only NM applicants, I mean) and from "elephants". As I said, I have no good solution, nor even concrete proposals (except "sometimes we need a leader to make decisions") but I really think there are things Debian (as a project) needs to improve.

There's a problem between gtk 2.12 and xfwm 4.4.1-2 and before. A deadlock may occurs which renders the session completely useless. The mouse still moves, and you can Ctrl+Alt+Backspace, but nothing else works. It's a gtk 2.12 change which is fixed in xfwm4 4.4.1-3, uploaded this morning. If you encounter this behavior, upgrade your xfwm and it should be ok. All archs aren't built yet, but buildds are keeping up.

if you like to monitor the number of RC bugs, you are probably annoyed by the graph on http://bugs.debian.org/release-critical/. The graph starts in 2003, making it impossible to read short-time changes. There’s a bug about that: #431299: RC bug status graph timescale is too long. And I provided a patch a few months ago, but it hasn’t been included yet. So, in the meantime, you can use my private copy (generated daily):

• Graph for the last two years
• Graph for the last 6 months
• Overall graph (same as the one on bugs.d.o, with the added captions)

Also, if you like graphs, Yves-Alexis Perez (aka Corsac) generates cool graphs about Debian:

• NEW queue
• NM stats

And if you want to have all the interesting graphs on the same page, you can use this page.

On his blog, Matt Kohut (an engineer from Lenovo) opened a poll about Linux on Thinkpads laptop. He posted yesterday about Linux on laptops and was surprised about the number of answer he had, so now he asks people what distribution would they prefer on their Thinkpad if Lenovo would start supporting a Linux distribution. So I thought Thinkpad owners in planet readers may want to express their opinion on the post.

Ok guys,

if suddenly your vim modelines don't work anymore, don't scratch your head and spend too much time looking for the problem in those (which were perfectly OK 2 days ago).

Vim maintainers disabled modelines in default config files since the last upload:

From /usr/share/doc/vim/changelog.Debian.gz:



And from /usr/share/vim/vim71/debian.vim:



The only thing you have to do is to explicitely enable modelines, acknowledging possible security problems, and add:



somewhere in your vimrc.

OTH.

We (the pkg-xfce team) are considering to drop xfmedia from Debian.

It has nasty bugs, isn't really well maintained upstream and I guess none of us use it. Some people use it, so maybe it's not a good idea to drop it, but in case you're using it and are greatly against the drop, please talk (to pkg-xfce mailing list and post comments), and offer your help.

Thanks!

blog posts I am going to identify all my DPL-related posts with a dpl tag. All such posts will be accessible through http://sam.zoy.org/blog/?cat=dpl. talks On May 5th I attended an Etch Install Party at the Carrefour du Num rique in the Cit des Sciences et de l'Industrie in Paris, organised by the Parinux LUG. Fellow developers Christian Perrier and Julien Cristau as well as not-yet-but-now-almost-really-soon-to-be developer Yves-Alexis Perez were also present. I did a (rather dull, sorry; I didn't prepare it well enough) talk about the Debian project, its organisation and how people, even beginners, can help Debian and its community. My slides (French) are available, and the Carrefour du Num rique people kindly recorded it and made it available for download. interviews Since the DPL elections I have given several interviews, of which a few have already been published. They may be of interest because I share my thoughts about topics that were not covered in my platform, or not very deeply. You can also check whether I am consistent. And it s important that people know what I may say about Debian to the rest of the world. The interviews are:

• by Sam Varghese on iTWire (also an OSNews story with comments)
• by Bruce Byfield on linux.com
• by French LUG RotomaLUG (audio file and very nice text version available); this one is supposed to be less formal and professional but the questions were very well organised

FTP-master and other teams Zobel is frustrated by things not happening in the FTP team which were apparently going better when AJ was DPL. I don t really know how to understand that blog post. A DPL+FTP-master hat is something that cannot happen this year, so if this is what allowed AJ to be efficient we ll have to find something else. For the record, after my first bits from the DPL on debian-devel-announce and its request for candidacy I have received one offer to help the DSA team and one offer (this morning) to help with the NEW-handling part of FTP-master work.

Ok, so Xfce 4.4.1 (bugfix release) is out since some days. I've packaged this new version, which is mostly ready in our svn. So 4.4.0 won't be uploaded to unstable at all, and we will upload directly 4.4.1 in sid in some days. The thing which blocked us to upload to unstable was gtk2.10, and it has been uploaded yesterday, so nothing is blocking now and we should be able to upload really soon.

The packages are available from my repository for ppc and sparc. I've changed the layout to add an UNRELEASED branch, so people using it are warned that those packages are even more unstable than unstable. Those packages are packages which have not been uploaded to debian, and thus may be unusable.

Alway prefer packages coming from pure Debian repositories, but if you want to test and help us correct mistakes, you can use the repository (and report bugs to our mailing list).

For etch users, I'll prepare 4.4.1 backports, but as I don't have hardware access, they will be only ppc and sparc binaries. Maybe other will be able to build backports for other arches.

Yves-Alexis Perez writes a bit about Debian and crypto-containers, comparing cryptsetup and encfs. The comparison is decent enough, except that it's fairly trivial to get cryptsetup to integrate into the whole gnome-volume-manager stack and have a dialogue pop up when you insert an encrypted USB stick or similar. Sure, it's mounted by a root process, but I wouldn't claim it's any kind of insecure because of that. What did really catch my eye was the line near the end:

[...] but this is a bruteforce attack against master password (1024 bits RSA key), not against 128bits aes key of the container.

Well, according to conventional research, a 1024 bit RSA key is about as strong as an 80 bit symmetric key. A semi-recent RSA paper confirms this too. And to the best of my knowledge, there has not been found weaknesses in AES which lower the effective key size.

Theses days, I've been looking for a way to have crypto-containers in Debian. I wanted something easy to use, easy to move but still quite secure, which wouldn't require root access to the box, and as an option could use my gpg key.

I looked closely at two projects:

* cryptsetup/luks

The nice thing is that you only have one file containing all your crypted filesystem, it uses the Linux unified key management system (luks), and you are able to use a gpg key to crypt the data. I didn't tried it yet, because there are some drawbacks which I find really important. It uses multiple commands for every operations (creating the container, mounting and unmounting it).

For creating the crypto container you need to:
- create the file
- use it as a loop device (root access)
- initialize the container
- open the container
- create a filesystem on it
- mount it

Each time you want to mount it, you need to:
- create the loop device from the file
- open the container
- mount it

It surely can be wrapped, but that may be difficult to deploy. And you need root access for all operations (you can mount/umount without it using fstab, pmount or things like that, but still it's using privilegied access). And the major drawback, I think, is that the container size is fixed. You choose it when you create the initial file which you'll mount as a loop device. I don't know if there's a way to extend it after creating crypto-container, but anyway it'll need to be manual.

* encfs

encfs is fuse-based, so it doesn't require anything, beside fuse support in the kernel and your user belonging to fuse group. No need to root access nor anything. You create the container with only one command, then mount or umount it with only one command too. You can add and remove files from the container without asking yourself about disk usage or something, because the container is "expanded" (see after) when you add files, automatically.

There are two drawbacks in encfs, for me:
- crypto-container isn't a file, but a folder, with files and folders using crypted filenames but real size. (more or less, because you can use options to modify it but you won't hide a 20MB file for example). It's less secure than a one-file crypto-container where you can't determine how many files there are in it (and with crypsetup/luks, you won't be able to determine how much space is used in the container as the size is fixed anyway). It's less easy to move around, put on an usb key or transmit. You can tar it, yes, but you lose the comfort.
- you can't use a gpg key

In the end, I guess I'd like something like .dmg OSX Disk Images, which can be encrypted. They are really easy to use, as far as I could have seen. Maybe not so secure, but this is a bruteforce attack against master password (1024 bits RSA key), not against 128bits aes key of the container.

Anyway, I've setup an encfs folder here, but am still looking for something wich would improve the situation.

Wouter asks why I wrote pommed instead of patching pbbuttonsd. First things first, pommed was originally named mbpeventd and targeted only at the MacBook Pro and MacBook laptops. The port to the PowerBook and iBook (which is what Wouter uses, I think) wasn’t a goal at first. pommed handles the hotkeys events and the ambient light sensors (if available) and that’s it. Nothing more. pbbuttonsd does a lot of other things that other pieces of software can handle far better than it does. I never ran it on my PowerBook and stuck to pmud; it did just what I needed it to do, and it did well. The kernel handled the LCD backlight all by itself, and I had no need for either the volume +/- keys or the eject key. When I got my MacBook Pro, I took a look at the various ways to get the hotkeys to work. Well, nothing worked. I discovered that pbbuttonsd was also available on i386/amd64 and gave it a try. IIRC I had to build it on amd64, and the Makefile already raised a couple of mental flags. But oh well. Then I tried to configure it, and discovered a gazillion configuration options, half of them unneeded. Anyway, I got to the point where it would run, and obviously there was some patching to be done to get it to play nice with the MacBook Pro. To put it simply: looking at the code made me cry. It’s horrible. Incredibly complicated and obfuscated for no good reason. At that point, patching was out of the question. Moreover, I never liked pbbuttonsd that much, for various reasons, ranging from its “let’s do everything!” policy to its SHM interface for the GUIs (come on, that’s the 21st century knocking at your door). So, in a nutshell:

• it’s a nightmare to configure
• it does a lot of things that I do not want it to do
• I really can’t look at that code for more than 30 seconds without yelling at it
• it’s faster to just write something new from scratch than to clean up pbbuttonsd
• DBus looked like a nice thing to play with, and this was an opportunity to give it a shot

I really like the KISS approach and the traditional UNIX way of doing things, so I tend to dislike most one size fits all software. It took me, what, 2 hours to build the first version of mbpeventd which handled the LCD and the keyboard backlight. That’s all the features I needed, past that point everything else was just pure bonus. As for the name… mbpeventd really sucked as a name, and it wasn’t a good name anymore once the PowerBook support got added. I did not want to go with something like “appled” because I did not want to use the name “Apple”, but that was the closest match. Then I thought “hmm, why not … translate it … pommed? … sold!”. The name is funny for both Corsac and I because it’s a fortune cookie from one of the IRC channels we’re both hanging on; as it happens, the fortune is about Apple hardware and how users can get lost with a one button mouse. So, why use pommed? Use it if you want something lightweight, fast and simple which won’t try to do everything for you. And you can even patch it and send me the patches!